ETSITS102 257vi.li 



(2003-08) 



Technical Specification 



Private Integrated Services Network (PISN); 

Inter-exchange Signalling Protocol; 

Make Call Request supplementary service 




ETSI TS 102 257 V1 .1 .1 (2003-08) 



Reference 



DTS/ECMA-00232 
Keywords 



PISN, QSIG, stage 3, supplementary service 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 

Tel. : +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N ° 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.org 

The present document may be made available in more than one electronic version or in print. In any case of existing or 

perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 

Information on the current status of this and other ETSI documents is available at 

http://portal.etsi.org/tb/status/status.asp 

If you find errors in the present document, send your comment to: 
editor@etsi.orq 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2003. 
All rights reserved. 

DECT™, PLUGTESTS™ and UMTS™ are Trade Marks of ETSI registered for the benefit of its Members. 
TIPHON™ and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. 
3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. 



ETSI 



ETSI TS 102 257 V1 .1 .1 (2003-08) 



Contents 



Intellectual Property Rights 6 

Foreword 6 

Brief History 6 

1 Scope 7 

2 Conformance 7 

3 References (normative) 7 

4 Definitions 8 

4.1 External definitions 8 

4.2 Other definitions 8 

4.2.1 Co-operating PINX 8 

4.2.2 Co-operating User 8 

4.2.3 Destination PINX 8 

4.2.4 Destination User 9 

4.2.5 Make Call Request 9 

4.2.6 Original Call 9 

4.2.7 Requested Call 9 

4.2.8 Requesting PINX 9 

4.2.9 Requesting User 9 

5 List of acronyms 9 

6 Signalling Protocol for the support of SS-MCR 10 

6.1 SS-MCR description 10 

6.2 SS-MCR operational requirements 10 

6.2.1 Requirements on a Requesting PINX 10 

6.2.2 Requirements on a Co-operating PINX 10 

6.2.3 Requirements on a Destination PINX 11 

6.2.4 Requirements on a Transit PINX 11 

6.3 SS-MCR coding requirements 12 

6.3.1 Operations 12 

6.3.2 Information elements 15 

6.3.2.1 Facility information element 15 

6.3.2.2 Other information elements 15 

6.3.3 Messages 15 

6.4 SS-MCR state definitions 15 

6.4.1 States at the Requesting PINX 15 

6.4.1.1 State MCR-Idle 15 

6.4.1.2 State MCR- Active 15 

6.4.2 States at the Co-operating PINX 15 

6.4.2.1 State MCR-Idle 15 

6.4.2.2 State MCR- Active 15 

6.4.3 States at the Destination PINX 16 

6.5 SS-MCR signalling procedures 16 

6.5.1 Actions at the Requesting PINX 16 

6.5.1.1 Normal procedures 16 

6.5.1.1.1 Activation/deactivation/interrogation 16 

6.5.1.1.2 Invocation and operation 16 

6.5.1.2 Exceptional procedures 16 

6.5.1.2.1 Activation/deactivation/interrogation 16 

6.5.1.2.2 Invocation and operation 16 

6.5.2 Actions at the Co-operating PINX 16 

6.5.2.1 Normal procedures 17 

6.5.2.1.1 Activation / deactivation / interrogation 17 

6.5.2.1.2 Invocation and operation 17 



ETSI 



4 ETSI TS 1 02 257 V1 .1 .1 (2003-08) 

6.5.2.2 Exceptional procedures 17 

6.5.2.2.1 Activation/deactivation/interrogation 17 

6.5.2.2.2 Invocation and operation 17 

6.5.3 Actions at the Destination PINX 18 

6.5.3.1 Normal procedures 18 

6.5.3.1.1 Activation / deactivation / interrogation 18 

6.5.3.1.2 Invocation and operation 18 

6.5.3.2 Exceptional procedures 18 

6.5.3.2.1 Activation / deactivation / interrogation 18 

6.5.3.2.2 Invocation and operation 18 

6.5.4 Actions at a Transit PINX 18 

6.6 SS-MCR impact of interworking with public ISDNs 18 

6.7 SS-MCR impact of interworking with non-ISDNs 18 

6.8 Protocol interactions between SS-MCR and other supplementary services and ANFs 18 

6.8.1 Calling Line Identification Presentation (SS-CLIP) 19 

6.8.2 Connected Line Identification Presentation (SS-COLP) 19 

6.8.3 Calling/Connected Line Identification Restriction (SS-CLIR) 19 

6.8.4 Calling Name Identification Presentation (SS-CNIP) 19 

6.8.5 Calling Name Identification Presentation (SS-CNIR) 19 

6.8.6 Connected Name Identification Presentation (SS-CONP) 19 

6.8.7 Completion of Call to Busy Subscriber (SS-CCBS) 19 

6.8.8 Completion of Call on No Reply (SS-CCNR) 19 

6.8.9 Call Transfer (SS-CT) 19 

6.8.10 Call Forwarding Unconditional (SS-CFU) 19 

6.8.11 Call Forwarding Busy (SS-CFB) 19 

6.8.12 Call Forwarding No Reply (SS-CFNR) 20 

6.8.13 Call Deflection (SS-CD) 20 

6.8.14 Path Replacement (ANF-PR) 20 

6.8.15 Call Offer (SS-CO) 20 

6.8.16 Call Intrusion (SS-CI) 20 

6.8.17 Do not Disturb (SS-DND) 20 

6.8.18 Do not Disturb Override (SS-DNDO) 20 

6.8.19 Advice of Charge (SS-AOC) 20 

6.8.20 Recall (SS-RE) 20 

6.8.21 Call Interception (ANF-CINT) 20 

6.8.22 Transit Counter (ANF-TC) 21 

6.8.23 Route Restriction Class (ANF-RRC) 21 

6.8.24 Message Waiting Indication (SS-MWI) 21 

6.8.25 Wireless Terminal Location Registration (SS-WTLR) 21 

6.8.26 Wireless Terminal Incoming Call (ANF-WTMI) 21 

6.8.27 Wireless Terminal Outgoing Call (ANF-WTMO) 21 

6.8.28 Wireless Terminal Authentication of a WTM User (SS-WTAT) 21 

6.8.29 Wireless Terminal Authentication of the PISN (SS-WTAN) 21 

6.8.30 Private User Mobility Incoming Call (ANF-PUMI) 21 

6.8.31 Private User Mobility Outgoing Call (ANF-PUMO) 21 

6.8.32 Private User Mobility Registration (SS-PUMR) 21 

6.8.33 Common Information (ANF-CMN) 21 

6.8.34 Call Priority Interruption (Protection) (SS-CPI(P)) 21 

6.8.35 Single Step Call Transfer (SS-SSCT) 21 

6.3.36 Simple Dialog (SS-SD) 22 

6.8.37 Global Call Identification and Call Linkage (ANF-CIDL) 22 

6.8.38 Short Message Service (SS-SMS) 22 

6.8.39 Message Centre Monitoring (SS-MCM) 22 

6.8.40 Mailbox Identification (SS-MID) 22 

6.9 SS-MCR parameter values (Timers) 22 

6.9.1 Timer Tl 22 

Annex A (normative): Protocol Implementation Conformance Statement (PICS) Proforma 23 

A.l Introduction 23 

A.2 Instructions for completing the PICS proforma 23 

A. 2.1 General structure of the PICS proforma 23 



ETSI 



5 ETSI TS 1 02 257 V1 .1 .1 (2003-08) 

A. 2. 2 Additional information 24 

A. 2. 3 Exception information 24 

A.3 PICS proforma for ECMA-344 24 

A. 3.1 Implementation identification 24 

A. 3. 2 Protocol summary 25 

A.3. 3 General 25 

A. 3. 4 Procedures 25 

A.3.5 Coding 26 

A. 3. 6 Timers 26 

Annex B (informative): Examples of Message Sequences 27 

B.l Example message sequences for invocation and operation of SS-MCR 28 

B.l.l Example message sequences without prior existing connection 28 

B.1.2 Example message sequences of a successful communication with a message centre 31 

Annex C (informative): Specification and Description Language (SDL) Representation of 

Procedures 32 

C.l SDL representation of SS-MCR at the Requesting PINX 33 

C.2 SDL representation of SS-MCR at the Co-operating PINX 34 

C.3 SDL representation of SS-MCR at the Destination PINX 35 

History 36 



ETSI 



ETSI TS 102 257 V1 .1 .1 (2003-08) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by ECMA on behalf of its members and those of the European 
Telecommunications Standards Institute (ETSI). 



Brief History 



The present document is one of a series of ECMA Standards defining services and signalling protocols applicable to 
Private Integrated Services Networks (PISNs). The series uses ISDN concepts as developed by ITU-T and conforms to 
the framework of International Standards for Open Systems Interconnection as defined by ISO/IEC. It has been 
produced under ETSI work item DTS/ECMA-00232. 

The present document specifies the signalling protocol for use at the Q reference point in support of the Make Call 
Request supplementary service. The protocol defined in the present document forms part of the PSS1 protocol 
(informally known as QSIG). 

The present document is based upon the practical experience of ECMA member companies and the results of their 
active and continuous participation in the work of ISO/IEC JTC1, ITU-T, ETSI and other international and national 
standardization bodies. It represents a pragmatic and widely based consensus. 
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Scope 



The present document specifies the signalling protocol for the support of the Supplementary Service Make Call Request 
(SS-MCR) at the Q reference point between Private Integrated services Network exchanges (PINXs) connected 
together within a Private Integrated Services Network (PISN). 

Supplementary service MCR enables a Requesting User to request a Co-operating User to establish a new Requested 
Call to a Destination User. This new Requested Call between the Co-operating and Destination User can be either a 
Basic call or a Call Independent Signalling Connection. 

The Q reference point is defined in ECMA-133 [1]. 

Service specifications are produced in three stages and according to the method specified in ETS 300 387 [6]. The 
present document contains the stage 3 specification for the Q reference point and satisfies the requirements identified by 
the stage 1 and stage 2 specifications in ECMA-343 [4]. 

The signalling protocol for SS-MCR operates on top of the signalling protocol for basic circuit switched call control, as 
specified in ECMA-143 [2], and uses certain aspects of the generic procedures for the control of supplementary services 
specified in ECMA-165 [3]. 

The present document also specifies additional signalling protocol requirements for the support of interactions at the 
Q reference point between SS-MCR and other supplementary services and ANFs. 

The present document is applicable to PINXs, which can interconnect to form a PISN. 



Conformance 



In order to conform to the present document, a PINX shall satisfy the requirements identified in the Protocol 
Implementation Conformance Statement (PICS) proforma in annex A. 

Conformance to the present document includes conforming to those clauses that specify protocol interactions between 
SS-MCR and other supplementary services and ANFs for which signalling protocols at the Q reference point are 
supported in accordance with the stage 3 standards concerned. 



References (normative) 



The following standards contain provisions, which, through reference in this text, constitute provisions of the present 
document. All standards are subject to revision, and parties to agreements based on the present document are 
encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. 

In the case of references to ECMA Standards that are aligned with ISO/IEC International Standards, the number of the 
appropriate ISO/IEC International Standard is given in brackets after the ECMA reference. 

[1] ECMA-133: "Private Integrated Services Network (PISN) - Reference Configuration for PISN 

Exchanges (PINX)", (International Standard ISO/IEC 1 1579-1). 

[2] ECMA-143: "Private Integrated Services Network (PISN) - Circuit Mode Bearer Services - Inter- 

Exchange Signalling Procedures and Protocol (QSIG-BC)", (International Standard 
ISO/IEC 11572). 

[3] ECMA-165: "Private Integrated Services Network (PISN) - Generic Functional Protocol for the 

Support of Supplementary Services - Inter-Exchange Signalling Procedures and Protocol 
(QSIG-GF)", (International Standard ISO/IEC 1 1582). 

[4] ECMA-343: "Private Integrated Services Network (PISN) - Specification, Functional Model and 

Information Flows - Make Call Request Supplementary Service (MCRSD)". 

[5] ECMA-345: "Private Integrated Services Network (PISN) - Use of QSIG for Message Centre 

Access (MCA) Profile Standard". 
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[6] ETSI ETS 300 387: "Private Telecommunication Network (PTN); Method for the specification of 

basic and supplementary services". 

[7] ITU-T Recommendation 1. 112: "Vocabulary of terms for ISDNs". 

[8] ITU-T Recommendation 1.210: "Principles of telecommunication services supported by an ISDN 

and the means to describe them". 

[9] ITU-T Recommendation Q.950: "Digital Subscriber Signalling System No. 1 (DSS1) - 

Supplementary services protocols, structure and general principles". 

[10] ITU-T Recommendation Z. 100: "Specification and Description Language (SDL)". 



4 Definitions 

For the purposes of the present document, the following terms and definitions apply. 

4.1 External definitions 

The present document uses the following terms and definitions given in other documents apply: 

Application Protocol Data Unit (APDU): See ECMA-165 [3]. 

call, basic call: See ECMA-165 [3]. 

Call Independent Signalling Connection (CISC): See ECMA-165 [3]. 

call-independent: See ECMA-165 [3]. 

gateway PINX: See ECMA-165 [3]. 

originating PINX: See ECMA-165 [3]. 

Private Integrated Services Network (PISN): See ECMA-133 [1]. 

Private Integrated services Network exchange (PINX): See ECMA-133 [1]. 

signalling: See ITU-T Recommendation 1.112 [7]. 

Supplementary Service (SS): See ITU-T Recommendation 1.210 [8]. 

Supplementary Service Control (SSC) entity: See ECMA-165 [3]. 

terminating PINX: See ECMA-165 [3]. 

transit PINX: See ECMA-165 [3]. 

4.2 Other definitions 

4.2.1 Co-operating PINX 

The PINX where the Co-operating User is located. 

4.2.2 Co-operating User 

The user who receives a Make Call Request and who shall set up a new Requested Call to the Destination User. 

4.2.3 Destination PINX 

The PINX where the Destination User is located. 
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4.2.4 Destination User 

The called user of the Requested Call i.e. the user to whom the Co-operating User shall establish a Requested Call. 

4.2.5 Make Call Request 

A request from the Requesting User for a new call (i.e. Requested Call) between a Co-operating User and a Destination 
User. 

4.2.6 Original Call 

The call between the Requesting User and the Co-operating User. The Original Call can be either a Basic call or a Call 
Independent Signalling Connection and is correlated with the Requested Call. 

4.2.7 Requested Call 

The call between the Co-operating User and the Destination User that is established by the Co-operating User due to a 
Make Call Request from the Requesting User. The Requested Call can either be a Basic call (with a specific Basic 
Service) or a Call Independent Signalling Connection and is correlated with the Original Call. 

4.2.8 Requesting PINX 

The PINX where the Requesting User is located. 

4.2.9 Requesting User 

The User who sends a Make Call Request to the Co-operating User with the request to establish a specific Requested 
Call to the Destination User. 



List of acronyms 



For the purposes of the present document the following acronyms apply: 

ANF Additional Network Feature 

ANF-CIDL Call Identification and Call Linkage 

ANF-PR Path Replacement 

ANF-PUMI Private User Mobility Incoming Call 

ANF-PUMO Private User Mobility Outgoing Call 

ANF-RRC Route Restriction Class 

ANF-TC Transit Counter 

APDU Application Protocol Data Unit 

ASN. 1 Abstract Syntax Notation One 

CISC Call Independent Signalling Connection 

ISDN Integrated Services Digital Network 

NFE Network Facility Extension 

PICS Protocol Implementation Conformance Statement 

PINX Private Integrated services Network eXchange 

PISN Private Integrated Services Network 

SDL Specification and Description Language 

SS Supplementary Service 

SS-AOC Advice of Charge 

SS-CCBS Completion of Calls to Busy Subscribers 

SS-CCNR Completion of Calls on No Reply 

SS-CD Call Deflection 

SS-CFB Call Forwarding Busy 

SS-CFNR Call Forwarding No Reply 

SS-CFU Call Forwarding Unconditional 
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SS-CI Call Intrusion 

SS-CINT Call INTerception 

SS-CLIP Calling Line Identification Presentation 

SS-CLIR Calling/Connected Line Identification Restriction 

SS-CMN Common Information 

SS-CNIP Calling Name Identification Presentation 

SS-CNIR Calling/Connected Name Identification Restriction 

SS-CO Call Offer 

SS-COLP Connected Line Identification Presentation 

SS-CONP Connected Name Identification Presentation 

SS-CPI(P) Call Priority Interruption (Protection) 

SS-CT Call Transfer 

SS-DND Do Not Disturb 

SS-DNDO Do Not Disturb Override 

SS-MCR Make Call Request 

SS-MID Mailbox Identification 

SS-MWI Message Waiting Indication 

SS-PUMR Private User Mobility Registration 

SS-RE REcall 

SS-SD Simple Dialog 

SS-SMS Short Message Service 

SS-SSCT Single Step Call Transfer 

SS-WTAN Wireless Terminal Authentication of the PISN 

SS-WTAT Wireless Terminal Authentication of a WTM User 

SS-WTLR Wireless Terminal Location Registration 

SS-WTMI Wireless Terminal Incoming Call 

SS-WTMO Wireless Terminal Outgoing Call 



Signalling Protocol for the support of SS-MCR 



6.1 SS-MCR description 



The supplementary service MCR enables a Requesting User to request a Co-operating User to establish a new 
Requested Call to a Destination User. This new Requested Call between the Co-operating User and the Destination 
User can either be a Basic call or a Call Independent Signalling Connection. The new Requested Call is correlated to the 
Original Call between the Requesting and Co-operating User. 

6.2 SS-MCR operational requirements 

6.2.1 Requirements on a Requesting PINX 

Call establishment procedures for the incoming and outgoing side of an inter-PINX link and call release procedures, as 
specified in ECMA-143 [2], shall apply. 

Generic procedures for call-related control of supplementary services, as specified in ECMA-165 [3] for an End PINX, 
shall apply. 

Generic procedures for the call-independent control (connection-oriented) of supplementary services, as specified in 
ECMA-165 [3] for an Originating PINX and for a Terminating PINX, shall apply. 

6.2.2 Requirements on a Co-operating PINX 

Call establishment procedures for the incoming and outgoing side of an inter-PINX link and call release procedures, as 
specified in ECMA-143 [2], shall apply. 

Generic procedures for call-related control of supplementary services, as specified in ECMA-165 [3] for an End PINX, 
shall apply. 
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Generic procedures for the call-independent control (connection-oriented) of supplementary services, as specified in 
ECMA-165 [3] for a Terminating PINX and for an Originating PINX, shall apply. 

6.2.3 Requirements on a Destination PINX 

Call establishment procedures for the incoming and outgoing side of an inter-PINX link and call release procedures, as 
specified in ECMA-143 [2], shall apply. 

Generic procedures for call-related control of supplementary services, as specified in ECMA-165 [3] for an End PINX, 
shall apply. 

Generic procedures for the call-independent control (connection-oriented) of supplementary services, as specified in 
ECMA-165 [3] for a Terminating PINX and for an Originating PINX, shall apply. 

6.2.4 Requirements on a Transit PINX 

Basic call procedures specified in ECMA-143 [2] for a Transit PINX shall apply. 

Generic procedures for call-related control of supplementary services, as specified in ECMA-165 [3] for a Transit 
PINX, shall apply. 

Generic procedures for the call-independent control (connection-oriented) of supplementary services, as specified in 
ECMA-165 [3] for a Transit PINX, shall apply. 
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6.3 SS-MCR coding requirements 
6.3.1 Operations 

The operations defined in Abstract Syntax Notation number 1 (ASN.l) in table 1 shall apply. 

Table 1 : Operations in support of SS-MCR 



SS-MCR-Operations-asn97 

{iso (1) identif ied-organization (3) icd-ecma (12) standard (0) 
qsig-make-call-request (344) make-call-request-operations (0)} 

DEFINITIONS EXPLICIT TAGS ::= 

BEGIN 

IMPORTS 

OPERATION, 

ERROR 

FROM Remote -Ope r at ions -Information-Objects 

{ joint-iso-itu-t (2) remote-operations (4) inf ormationOb jects (5) versionl (0) 



EXTENSION, 

Extension { } 

FROM Manuf acturer-specif ic-service-extension-class-asnl-97 

{ iso (1) standard (0) pssl-generic-procedures (11582) msi-class-asnl-97 (11) 

Name 

FROM Name-Operations-asnl-97 

{ iso (1) standard (0) pssl-name (13868) name-operations-asnl-97 (1) } 

BasicService 

FROM Call -Divers ion-Operations-asnl-97 
{ iso (1) standard (0) pssl-call-diversion (13873) 
call-diversion-operations-asnl-97 (1) } 

basicServiceNot Provided, 

supplementaryServicelnteractionNotAllowed, 

userNot Sub scribed 

FROM General-Error-List 

{itu-t (0) recommendation (0) q (17) 950 (950) general-error-list (1)} 

Pre sent edAddressUnscreened 
FROM Address ing-Data-Elements-asnl-97 

{ iso (1) standard (0) pssl-generic-procedures (11582) 
addressing-data-elements-asnl-97 (20) } 

Callldentity, establishmentFailure 

FROM Path-Replacement-Operations-asnl-97 

{iso (1) standard (0) pssl-path-replacement (13874) pr-operations-asnl-97 (1) ] 



Make-Call-Request-Operations OPERATION: : : 
mCRequest | mCAlerting | mCInform } 
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Table 1 : Operations in support of SS-MCR (continued) 



mCRequest OPERATION : 


= { 




ARGUMENT 




MCRequestArg 


RESULT 




MCRequestResult 


ERRORS 




{userNot Subscribed | 
basicServiceNotProvided | 

supplementaryServicelnteractionNotAllowed | 
invalidDestinationNumber | 
invalidCooperationNumber | 
mCRequestNotAllowed | 
mCExecutionNotAllowed | 
mCDestUserBusy | 
mCCoopUserBusy | 
mCCoopUserRe jected | 
establishmentFailure | 
unspecified} 


CODE 


} 


local: 112 


mCInform OPERATION : 


= { 




ARGUMENT 




MCInformArg 


RETURN RESULT 


FALSE 


ALWAYS RESPONDS 


FALSE 


ERRORS 




{userNot Subscribed | 
basicServiceNotProvided | 

supplementaryServicelnteractionNotAllowed | 
invalidDestinationNumber | 
mCExecutionNotAllowed | 
mCDestUserBusy | 
unspecified} 


CODE 




local: 113 
} 


mCAlerting OPERATION : 


= { 




ARGUMENT 




MCAlertingArg 


RETURN RESULT 


FALSE 


ALWAYS RESPONDS 


FALSE 


CODE 


} 


local: 114 


MCRequestArg ::= 
{ 
callType 


SEQUENCE 




CallType, 


retainOrigCall 


BOOLEAN DEFAULT TRUE, 


destinationAddr 


ess PresentedAddressUnscreened, 


requestingAddress [0] PresentedAddressUnscreened OPTIONAL, 


cooperatingAddress [1] PresentedAddressUnscreened OPTIONAL, 


correlation 




Correlation, 


extensions 
} 

MCRequestResult ::= 
{ 
extensions 

} 




MCRExtensions OPTIONAL, 


SEQUENCE 




MCRExtensions OPTIONAL, 
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Table 1 : Operations in support of SS-MCR (concluded) 



MCInformArg 



SEQUENCE 



requestingAddress 
cooperatingAddress 
correlation 
extensions 



[0] PresentedAddressUnscreened OPTIONAL, 

[1] PresentedAddressUnscreened OPTIONAL, 

Correlation, 

MCRExtensions OPTIONAL, 



} 



MCAlertingArg 



SEQUENCE 



correlation 
extensions 



CallType 



CHOICE 



basicService 
cisc 



Correlation, 
MCRExtensions 



BasicService, 
NULL 



OPTIONAL, 



Correlation 



: := SEQUENCE 
{ 

correlationData 
correlationReason 



Callldentity, 
CorrelationReason 



OPTIONAL 



eason : : = 
{ 

unknown 


INTEGER 


(0), 


mC AC ommu n i c a t i o n 


(1), 


cTIApplication 


(2) 


} (0..255) 





MCRExtensions 



CHOICE 



none 
single 

multiple 



NULL, 
[0] IMPLICIT Extension 

{ { MakeCallRequestExtension } 
[1] IMPLICIT SEQUENCE OF Extension 

{ { MakeCallRequestExtension } 



MakeCallRequestExtension EXTENSION: 



invalidDestinationNumber ERROR 

invalidCooperationNumber ERROR 

mCRequestNotAllowed ERROR 

mCExecutionNotAllowed ERROR 

mCDestUserBusy ERROR 

mCCoopUserBusy ERROR 

mCCoopUserRe jected ERROR 

unspecified ERROR 



[CODE local 

[CODE local 

[CODE local 

[CODE local 

[CODE local 

[CODE local 



1030] 
1031] 
1032] 
1033] 
1034] 
1035] 
1036] 



{CODE local 
{PARAMETER Extension 
{ { MakeCallRequestExtension 
CODE local : 1008 



END 



of SS-MCR-Operations 
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6.3.2 Information elements 

6.3.2.1 Facility information element 

The operations defined in clause 6.3.1 shall be coded in the Facility information element in accordance with 
ECMA-165 [3]. 

When conveying the invoke APDUs of the operations defined in clause 6.3.1, the destination Entity data element of the 
NFE shall contain the value endPINX. 

When conveying the invoke APDU of operation mCRequest defined in clause 6.3.1, the interpretation APDU shall be 
set to value reject AnyUnrecognisedlnvokePdu or shall be omitted. 

When conveying the invoke APDU of operation mCInform or mCAlerting defined in clause 6.3.1, the interpretation 
APDU shall be set to value discardAnyUnrecognisedlnvokePdu. 

6.3.2.2 Other information elements 

Any other information element shall be coded in accordance with ECMA-143 [2]. 

6.3.3 Messages 

The Facility information element shall be conveyed in messages as specified in clause 10 of ECMA-165 [3]. 

6.4 SS-MCR state definitions 

6.4.1 States at the Requesting PINX 

The procedures for the Requesting PINX are written in terms of the following conceptual states existing within the 
SS-MCR Control entity in that PINX in association with a particular SS-MCR request from the Requesting User. 

6.4.1.1 State MCR-ldle 

SS-MCR is not operating. 

6.4.1.2 State MCR- Active 

SS-MCR is operating. A mCRequest invoke APDU was sent to the Co-operating PINX. The Requesting PINX awaits 
the result of this operation. 

6.4.2 States at the Co-operating PINX 

The procedures for the Co-operating PINX are written in terms of the following conceptual states existing within the 
SS-MCR Control entity in that PINX. 

6.4.2.1 State MCR-ldle 

SS-MCR is not operating. 

6.4.2.2 State MCR-Active 

SS-MCR is operating. Call establishment of the requested call is initiated by the Co-operating PINX and a mCInform 
invoke APDU was sent towards the Destination PINX. The Co-operating PINX awaits the result of the call 
establishment. 
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6.4.3 States at the Destination PINX 

No SS-MCR specific states required. 

6.5 SS-MCR signalling procedures 

Examples of message sequences are shown in annex B. 

6.5.1 Actions at the Requesting PINX 

The SDL representation of procedures at the Requesting PINX is shown in clause C.l. 

6.5.1.1 Normal procedures 

6.5.1.1.1 Activation/deactivation/interrogation 

Not applicable. 

6.5.1 .1 .2 Invocation and operation 

In state MCR-Idle, due to a request from the Requesting User, the Requesting PINX shall send a mCRequest invoke 
APDU to the Co-operating PINX, start Timer Tl and enter state MCR-Active. 

For the transport of this mCRequest invoke APDU the Requesting PINX shall either use the Call Reference of an 
already existing Basic Call or an already existing Call Independent Signalling Connection or set up a new Call 
Independent Signalling Connection in accordance with the procedures specified in clause 7.3 of ECMA-165 [3] In the 
case of set up of a new Call Independent Signalling Connection, the Requesting PINX is responsible for the clearing of 
this connection. 

The elements callType, retainOrigCall, destinationAddress, requestingAddress, cooperatingAddress and correlation of 
the mCRequest invoke APDU shall be set according to the request of the Requesting User. 

NOTE: Provision of element cooperatingAddress is required when a new CISC is to be established. If 

mCRequest. inv is sent on the call reference of an already existing connection, the Co-operating User is 
the User served on this call reference at the Co-operating PINX. 

In state MCR-Active, on receipt of a mCAlerting invoke APDU from the Co-operating PINX, the Requesting PINX 
may indicate the result to the Requesting User, if the capability exists, and remain in state MCR-Active. 

In state MCR-Active, on receipt of a mCRequest return result APDU from the Co-operating PINX, the Requesting 
PINX shall stop Timer Tl, may indicate the result to the Requesting User if the capability exists, and shall enter state 
MCR-Idle. 

6.5.1.2 Exceptional procedures 

6.5.1 .2.1 Activation/deactivation/interrogation 

Not applicable. 

6.5.1 .2.2 Invocation and operation 

In state MCR-Active, on receipt of either a mCRequest reject APDU or a mCRequest return error APDU from the 
Co-operating PINX or on Timer Tl expiry, the Requesting PINX may send an appropriate error indication to the 
Requesting User if the capability exists, shall stop Timer Tl if running, and shall enter state MCR-Idle. 

6.5.2 Actions at the Co-operating PINX 

The SDL representation of procedures at the Co-operating PINX is shown in clause C.2. 
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6.5.2.1 Normal procedures 

6.5.2.1.1 Activation / deactivation / interrogation 

Not applicable. 

6.5.2.1 .2 Invocation and operation 

In State MCR-Idle, on receipt of a mCRequest invoke APDU from the Requesting PINX, the Co-operating PINX 
examines the received information and checks whether the make call request is allowed to be performed. If necessary, 
the Co-operating User may be prompted in an implementation specific manner prior to sending the SETUP message for 
the Requested Call. 

NOTE 1: A successful check may depend on the necessary Bearer Capability, user prompting and other 
implementations specific options. 

If SS-MCR is allowed to be performed, the Co-operating PINX shall store the information received in elements 
correlation and retainOrigCall for further usage and send a SETUP message towards the Destination PINX conveying: 

• a Called Party IE with the information as received in element destinationAddress, 

• a Bearer Capability IE and a Channel Identification IE appropriate for the information received in element 
callType, 

• a Facility IE with a mCInform invoke APDU conveying information as received in the elements: 

requestingAddress, 

cooperatingAddress, 

and correlation of the mCRequest invoke APDU. 

NOTE 2: Other additional Facility IEs may be sent together with this SETUP message. 

Afterwards the Co-operating PINX shall enter State MCR-Active. 

In State MCR-Active, on receipt of an ALERTING message from the Destination PINX, the Co-operating PINX shall 
send a mCAlerting invoke APDU towards the Requesting PINX in a FACILITY message. The element correlation shall 
be set as received in the mCRequest invoke APDU. 

In State MCR-Active, on receipt of a CONNECT message from the Destination PINX, the Co-operating PINX shall 
send a mCRequest return result APDU towards the Requesting PINX in a FACILITY message or, in the first call 
clearing message, if element retainOrigCall with value FALSE was received in State MCR-Idle. 

6.5.2.2 Exceptional procedures 

6.5.2.2.1 Activation/deactivation/interrogation 

Not applicable. 

6.5.2.2.2 Invocation and operation 

In State MCR-Idle on receipt of a mCRequest invoke APDU from the Requesting PINX, if: 

• the make call request is not allowed to be performed or 

• the Co-operating User is found busy or 

• the Co-operating User rejects the request after prompting, 

the Co-operating PINX shall send a mCRequest return error APDU indicating an appropriate error condition towards 
the Requesting PINX and remain in State MCR-Idle. 
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In State MCR- Active, on call failure, unexpected call clearing or receipt of a busy indication from the Destination User, 
the Co-operating PINX shall send a mCRequest return error APDU indicating an appropriate error condition in a 
FACILITY message or in the first call clearing message, if retainOrigCall was set to FALSE, towards the Requesting 
PINX and enter State MCR-Idle. 

In State MCR- Active, on receipt of a mCInform return error APDU from the Destination PINX the Co-operating PINX 
shall map the mCInform return error APDU into a mCRequest return error APDU indicating the same error condition, 
send it in a FACILITY message or in the first call clearing message, if retainOrigCall was set to FALSE, towards the 
Requesting PINX and enter State MCR-Idle. 

6.5.3 Actions at the Destination PINX 

The SDL representation of procedures at the Destination PINX is shown in clause C.3. 

6.5.3.1 Normal procedures 

6.5.3.1.1 Activation / deactivation / interrogation 

Not applicable. 

6.5.3.1 .2 Invocation and operation 

On receipt of a mCInform invoke APDU from the Co-operating PINX, the Destination PINX may indicate the received 
information to the Destination User if the capability exists. 

6.5.3.2 Exceptional procedures 

6.5.3.2.1 Activation / deactivation / interrogation 

Not applicable. 

6.5.3.2.2 Invocation and operation 

On receipt of the mCInform invoke APDU from the Co-operating PINX, and if the Destination User is found busy or 
another error condition is found, the Destination PINX shall send a mCInform return error APDU indicating the 
appropriate error condition towards the Co-operating PINX. 

6.5.4 Actions at a Transit PINX 

Not applicable. 

6.6 SS-MCR impact of interworking with public ISDNs 

Not applicable. 

6.7 SS-MCR impact of interworking with non-ISDNs 

Not applicable. 

6.8 Protocol interactions between SS-MCR and other 
supplementary services and ANFs 

This clause specifies protocol interactions with other supplementary services and ANFs for which stage 3 standards had 
been published at the time of publication of the present document. For interactions with supplementary services and 
ANFs for which stage 3 standards are published subsequent to the publication of the present document, see those other 
stage 3 standards. 
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NOTE 1: Simultaneous conveyance of APDUs for SS-MCR and another supplementary service or ANF in the same 
message, each in accordance with the requirements of its respective stage 3 standard, does not, on its own, 
constitute a protocol interaction. 

NOTE 2: Specific applications of the present document may restrict these interactions. 

6.8.1 Calling Line Identification Presentation (SS-CLIP) 

No protocol interaction. 

6.8.2 Connected Line Identification Presentation (SS-COLP) 

No protocol interaction. 

6.8.3 Calling/Connected Line Identification Restriction (SS-CLIR) 

No protocol interaction. 

6.8.4 Calling Name Identification Presentation (SS-CNIP) 

No protocol interaction. 

6.8.5 Calling Name Identification Presentation (SS-CNIR) 

No protocol interaction. 

6.8.6 Connected Name Identification Presentation (SS-CONP) 

No protocol interaction. 

6.8.7 Completion of Call to Busy Subscriber (SS-CCBS) 

No protocol interaction. 

6.8.8 Completion of Call on No Reply (SS-CCNR) 

No protocol interaction. 

6.8.9 Call Transfer (SS-CT) 

No protocol interaction. 

6.8.10 Call Forwarding Unconditional (SS-CFU) 

If the Co-operating User has activated SS-CFU, the request to establish a new Requested Call shall not be forwarded. 
The Co-operating PINX shall, as an implementation option, either override execution of SS-CFU and prompt the 
Co-operating User as specified in clause 6.5.2.1.2 or send a mCRequest return error APDU indicating an appropriate 
error value towards the Requesting PINX. 

SS-CFU, activated at the Destination User, is not affected by SS-MCR, i.e. the Requested Call may be forwarded. 

6.8.1 1 Call Forwarding Busy (SS-CFB) 

If a Co-operating User has activated SS-CFB, the request to establish a new Requested Call shall not be forwarded and 
the Co-operating PINX shall send a mCRequest return error APDU indicating an appropriate error value towards the 
Requesting PINX. 
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SS-CFB, activated at the Destination User, is not affected by SS-MCR, i.e. the Requested Call may be forwarded. 

6.8.12 Call Forwarding No Reply (SS-CFNR) 

If the Co-operating User has activated SS-CFNR, the request to establish a new Requested Call shall not be forwarded. 
The Co-operating PINX shall, as an implementation option, either override execution of SS-CFNR and prompt the 
Co-operating User as specified in clause 6.5.2.1.2 or send a mCRequest return error APDU indicating an appropriate 
error value towards the Requesting PINX. 

SS-CFNR, activated at the Destination User, is not affected by SS-MCR, i.e. the Requested Call may be forwarded. 

6.8.13 Call Deflection (SS-CD) 

Deflection of the request to establish a new Requested Call shall not be allowed. The Co-operating PINX shall, as an 
implementation option, either override execution of SS-CD and prompt the Co-operating User as specified in 
clause 6.5.2.1.2 or send a mCRequest return error APDU indicating an appropriate error value towards the Requesting 
PINX. 

SS-CD, activated at the Destination User, is not affected by SS-MCR, i.e. the Requested Call may be deflected. 

6.8.14 Path Replacement (ANF-PR) 

No protocol interaction. 

6.8.15 Call Offer (SS-CO) 

No protocol interaction. 

6.8.16 Call Intrusion (SS-CI) 

No protocol interaction. 

6.8.1 7 Do not Disturb (SS-DND) 

On receipt of a mCRequest invoke APDU and if the Co-operating User has activated SS-DND, it is an implementation 
option whether SS-DND or SS-MCR is performed. If SS-DND overrides, the Co-operating PINX shall send a 
mCRequest return error APDU indicating an appropriate error value towards the Requesting PINX. 

On receipt of a mCInform invoke APDU and if the Destination User has activated SS-DND, it is an implementation 
option whether SS-DND or SS-MCR is performed. If SS-DND overrides, the Destination PINX shall send a mCInform 
return error APDU indicating an appropriate error value towards the Co-Operating PINX. 

6.8.1 8 Do not Disturb Override (SS-DNDO) 

No protocol interaction. 

6.8.19 Advice of Charge (SS-AOC) 

No protocol interaction. 

6.8.20 Recall (SS-RE) 

No protocol interaction. 

6.8.21 Call Interception (ANF-CINT) 

No protocol interaction. 
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6.8.22 Transit Counter (ANF-TC) 

No protocol interaction. 

6.8.23 Route Restriction Class (ANF-RRC) 

No protocol interaction. 

6.8.24 Message Waiting Indication (SS-MWI) 

No protocol interaction. 

6.8.25 Wireless Terminal Location Registration (SS-WTLR) 

No protocol interaction. 

6.8.26 Wireless Terminal Incoming Call (ANF-WTMI) 

No protocol interaction. 

6.8.27 Wireless Terminal Outgoing Call (ANF-WTMO) 

No protocol interaction. 

6.8.28 Wireless Terminal Authentication of a WTM User (SS-WTAT) 

No interaction 

6.8.29 Wireless Terminal Authentication of the PISN (SS-WTAN) 

No protocol interaction. 

6.8.30 Private User Mobility Incoming Call (ANF-PUMI) 

No protocol interaction. 

6.8.31 Private User Mobility Outgoing Call (ANF-PUMO) 

No protocol interaction. 

6.8.32 Private User Mobility Registration (SS-PUMR) 

No protocol interaction. 

6.8.33 Common Information (ANF-CMN) 

No protocol interaction. 

6.8.34 Call Priority Interruption (Protection) (SS-CPI(P)) 

No protocol interaction. 

6.8.35 Single Step Call Transfer (SS-SSCT) 

No protocol interaction. 
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6.3.36 Simple Dialog (SS-SD) 

No protocol interaction. 

6.8.37 Global Call Identification and Call Linkage (ANF-CIDL) 

On receipt of a callldentificationAssign invoke APDU together with a mCRequest invoke APDU from the Requesting 
PINX, the Co-operating PINX shall send a callldentificationAssign invoke APDU using the same threadID as received 
from the Requesting PINX towards the Destination PINX together with the mCInform invoke APDU. 

6.8.38 Short Message Service (SS-SMS) 

No protocol interaction. 

6.8.39 Message Centre Monitoring (SS-MCM) 

No protocol interaction. 

6.8.40 Mailbox Identification (SS-MID) 

No protocol interaction. 

6.9 SS-MCR parameter values (Timers) 
6.9.1 Timer T1 

This timer shall be started by the Requesting PINX when a mCRequest invoke APDU is sent to the Co-operating PINX. 
The timer shall be stopped on receipt of a return result, return error or reject APDU of the mCRequest operation. The 
expiry of this timer shall be equivalent to the receipt of a reject APDU. 

Timer Tl shall have a value not less than 50 seconds. 

NOTE: When setting timer Tl, the value of Basic Call timer T310 as administrated in the PISN should be 
considered. 
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Annex A (normative): 

Protocol Implementation Conformance Statement (PICS) 

Proforma 



A.1 Introduction 



The supplier of a protocol implementation, which is claimed to conform to the present document shall complete the 
following Protocol Implementation Conformance Statement (PICS) proforma. 

A completed PICS proforma is the PICS for the implementation in question. The PICS is a statement of which 
capabilities and options of the protocol have been implemented. The PICS can have a number of uses, including use: 

• by the protocol implementor, as a check-list to reduce the risk of failure to conform to the standard through 
oversight; 

• by the supplier and acquirer, or potential acquirer, of the implementation, as a detailed indication of the 
capabilities of the implementation, stated relative to the common basis for understanding provided by the 
standard's PICS proforma; 

• by the user or potential user of the implementation, as a basis for initially checking the possibility of 
interworking with another implementation - while interworking can never be guaranteed, failure to interwork 
can often be predicted from incompatible PICSs; 

• by a protocol tester, as the basis for selecting appropriate tests against which to assess the claim for 
conformance of the implementation. 



A.2 Instructions for completing the PICS proforma 
A.2.1 General structure of the PICS proforma 

The PICS proforma is a fixed-format questionnaire divided into clauses each containing a group of individual items. 
Each item is identified by an item number, the name of the item (question to be answered), and the reference(s) to the 
clause(s) that specifies (specify) the item in the main body of the present document. 

The "Status" column indicates whether an item is applicable and if so whether support is mandatory or optional. The 
following terms are used: 

m mandatory (the capability is required for conformance to the protocol) 

o optional (the capability is not required for conformance to the protocol, but if the capability is 

implemented it is required to conform to the protocol specifications) 

o.<n> optional, but support of at least one of the group of options labelled by the same numeral <n> is 

required 

x prohibited 

<c.cond> conditional requirement, depending on support for the item or items listed in condition <cond> 

<item>:m simple conditional requirement, the capability being mandatory if item number <item> is 

supported, otherwise not applicable 

<item>:o simple conditional requirement, the capability being optional if item number <item> is supported, 

otherwise not applicable 
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Answers to the questionnaire items are to be provided either in the "Support" column, by simply marking an answer to 
indicate a restricted choice (Yes or No), or in the "Not Applicable" column (N/A). 

A.2.2 Additional information 

Items of additional information allow a supplier to provide further information intended to assist the interpretation of 
the PICS. It is not intended or expected that a large quantity will be supplied, and a PICS can be considered complete 
without any such information. Examples might be an outline of the ways in which a (single) implementation can be set 
up to operate in a variety of environments and configurations. 

References to items of additional information may be entered next to any answer in the questionnaire, and may be 
included in items of exception information. 



A.2.3 Exception information 



It may occasionally happen that a supplier will wish to answer an item with mandatory or prohibited status (after any 
conditions have been applied) in a way that conflicts with the indicated requirement. No pre-printed answer will be 
found in the Support column for this. Instead, the supplier is required to write into the Support column an x.<i> 
reference to an item of exception information, and to provide the appropriate rationale in the exception item itself. 

An implementation for which an exception item is required in this way does not conform to the present document. A 
possible reason for the situation described above is that a defect in the standard has been reported, a correction for 
which is expected to change the requirement not met by the implementation. 



A.3 PICS proforma for ECMA-344 
A.3.1 Implementation identification 



Supplier 




Contact point for queries about the 
PICS 




Implementation name(s) and version(s) 




Other information necessary for full 
identification, e.g., name(s) and 
version(s) for machines and/or 
operating systems; system name(s) 





Only the first three items are required for all implementations; other information may be completed as appropriate in 
meeting the requirement for full identification. 

The terms name and version should be interpreted appropriately to correspond with a supplier's terminology (e.g. type, 
series, model). 
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A.3.2 Protocol summary 



Protocol version 


1.0 


Addenda implemented (if applicable) 




Amendments implemented 




Have any exception items been required? 
(see clause A.2.3)? 


No [ ] Yes [ ] 

(The answer Yes means that the implementation does not 

conform to the present document) 



Date of Statement 





A.3.3 General 



Item 


Question/feature 


References 


Status 


N/A 


Support 


Al 


Behaviour as Requesting PINX for SS-MCR 




0.1 




Yes [ ] No[ ] 


A2 


Behaviour as Co-operating PINX for SS-MCR 




0.1 




Yes[] No[] 


A3 


Behaviour as Destination PINX for SS-MCR 




0.1 




Yes[] No[] 



A.3.4 Procedures 



Item 


Question/feature 


References 


Status 


N/A 


Support 


Bl 


Support of relevant ECMA-143 and ECMA-165 
procedures at the Requesting PINX 


6.2.1 


Al:m 




m:Yes [ ] 


B2 


Support of relevant ECMA-143 and ECMA-165 
procedures at the Co-operating PINX 


6.2.2 


A2:m 




m:Yes [ ] 


B3 


Support of relevant ECMA-143 and ECMA-165 
procedures at the Destination PINX 


6.2.3 


A3:m 




m:Yes [ ] 


B4 


Procedures at the Requesting PINX for invocation 
and operation 


6.5.1 


Al:m 




m:Yes [ ] 


B5 


Procedures at the Co-operating PINX for 
invocation and operation 


6.5.2 


A2:m 




m:Yes [ ] 


B6 


Procedures at the Destination PINX for invocation 
and operation 


6.5.3 


A3:m 




m:Yes [ ] 
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A.3.5 Coding 



Item 


Question/feature 


References 


Status 


N/A 


Support 


CI 


Sending of mCRequest invoke APDU to the 
Co-operating PINX 


6.5.1 


Al:m 




m:Yes [ ] 


C2 


Receipt of mCRequest return result APDU or 
mCRequest return error from the Co-operating 
PINX 


6.5.1 


Al:m 




m:Yes [ ] 


C3 


Receipt of mCRequest invoke APDU from the 
Requesting PINX 


6.5.2 


A2:m 




m:Yes [ ] 


C4 


Sending of mCRequest return result APDU or 
mCRequest return error APDU in case of an error 
indication 


6.5.2 


A2:m 




m:Yes [ ] 


C5 


Sending of mCAlerting invoke APDU to the 
Requesting PINX 


6.5.2 


A2:m 




m:Yes [ ] 


C6 


Receipt of mCAlerting invoke APDU from the 
Co-operating PINX 


6.5.1 


Al:m 




m:Yes [ ] 


C7 


Sending of mCInform invoke APDU to the 
Destination PINX 


6.5.2 


A2:m 




m:Yes [ ] 


C8 


Receipt of mCInform return error APDU from the 
Destination PINX 


6.5.2 


A2:m 




m:Yes [ ] 


C9 


Receipt of mCInform invoke APDU from the 
Co-operating PINX 


6.5.3 


A3:m 




m:Yes [ ] 


CIO 


Sending of mCInform return error APDU to the 
Co-operating PINX 


6.5.3 


A3:m 




m:Yes [ ] 



A.3.6 Timers 



Item 


Question/feature 


References 


Status 


N/A 


Support 


D1 


Support of timer Tl 


6.9.1 


A1:m 


[] 


m: Yes [ ] 
Value [....] 
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Annex B (informative): 
Examples of Message Sequences 



This annex describes some typical message flows for SS-MCR. The following conventions are used in the figures of 
this annex. 

1) The following notation is used: 



"► Basic call message containing SS-MCR information 
-► Basic call Message without SS-MCR information 



Call Independent Signalling Connection messages containing SS-MCR information 
Call Independent Signalling Connection messages without SS-MCR information 

SS-MCR information for the connected users 



xxx. inv Invoke APDU for operation xxx 

xxx.rr Return result APDU for operation xxx 

xxx.re Return error APDU for operation xxx 

2) The figures show messages exchanged via Protocol Control between PINXs involved in SS-MCR. Only 
messages relevant to SS-MCR are shown. 

3) Only the relevant information content (e.g. remote operation APDUs, notifications, information elements) is 
listed below each message name. The Facility and Notification indicator information elements containing 
remote operation APDUs and notifications are not explicitly shown. Information with no impact on SS-MCR 
is not shown. 
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B.1 Example message sequences for invocation and 
operation of SS-MCR 

B.1 .1 Example message sequences without prior existing 
connection 

Figure B.1 shows an example of successful invocation and operation of SS-MCR. The Requesting PINX initiates 
establishment of a Basic Call. A CISC is to be established before invocation of SS-MCR. The connection between 
Requesting PINX and Co-operating PINX is released after successful Call establishment as requested in the mCRequest 
invoke APDU. 



Requesting 
PINX 



Co-operating 
PINX 



SETUP 
mCRequest. inv 

CONNECT 



FACILITY 



mCAIerting.inv 
RELEASE 



mCRequest. rr 



RELEASE COMPLETE 



SETUP 



mClnform.inv 
CALL PROC 



ALERTING 



CONNECT 



Basic Call 



Destination 
PINX 



Figure B.1 : Example of successful invocation and operation of SS-MCR 
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Figure B.2 shows an example of successful invocation and operation of SS-MCR initiated by the Requesting PINX in 
case of an already existing CISC before invocation of SS-MCR. The connection between Requesting PINX and 
Co-operating PINX is retained after successful Call establishment. 



Requesting 
PINX 



Co-operating 
PINX 



CISC Connection 



FACILITY 
mCRequest.inv 

FACILITY 



mCAIerting.inv 
FACILITY 



mC Request, rr 



SETUP 



mClnform.inv 
CALLPROC 



ALERTING 



CONNECT 



Basic Call 



Destination 
PINX 



Figure B.2: Example of successful invocation and operation of SS-MCR 
using an already existing CISC 
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Figures B.3 and B.4 show examples of unsuccessful invocation and operation of SS-MCR initiated by the Requesting 
PINX due to different error conditions. 



Requesting 
PINX 



Co-operating 
PINX 



n 




n 


[ 


CISC 




FACILITY 




SETUP 


mCRequest.inv 
FACILITY 


mClnform.inv 
CALL PROC 


RELEASE 


mC Request, re 


REL COMP 




CISC 


u 




u 


I 



Destination Destination 
PINX User 



Setup ind 



Busy ind. 



Figure B.3: Example of unsuccessful invocation of SS-MCR 
due to busy Destination User 



Requesting 
PINX 



a 



Co-operating 
PINX 



n 



CISC 



FACILITY 



mCRequest.inv 

FACILITY 
mC Request, re 



CISC 



Destination 
PINX 



Figure B.4: Example of unsuccessful invocation of SS-MCR 
due to not allowed request 
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B.1 .2 Example message sequences of a successful 
communication with a message centre 

Figure B.5 shows an example for an application of SS-MCR for a Message Centre Application. Here the Requesting 
and Destination PINX are co-located at a Message Centre PINX complying with Profile-4 as defined in ECMA-345 [5]. 
SS-MCR is used in order to switch on/off a B-Channel for listening to a message. An already established CISC is used 
to signal to the Served/Co-operating PINX, that an additional B-Channel is needed. After retrieval of the message the 
B-channel is switched off again. 



Requesting/ 

Destination 

PINX 



Co-operating 
PINX 



CISC (1) 



LT 



FACILITY (1) 
mCRequest.inv 
SETUP (2) 



mClnform.inv 
CONNECT (2) 



FACILITY (1) 



mC Request, res 



Basic Call (2) 



DISCONNECT (2) 



CISC (1) 



Figure B.5: Example of successful invocation for SS-MCR with prior existing connection 
between a Co-operating PINX and a co-located Requesting/Destination PINX 
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Annex C (informative): 

Specification and Description Language (SDL) 

Representation of Procedures 

The diagrams in this annex use the Specification and Description Language defined in 
ITU-T Recommendation Z. 100 [10]. 

Each diagram represents the behaviour of an SS-MCR Supplementary Service Control entity at a particular type of 
PINX. In accordance with the protocol model described in ECMA-165 [3], the Supplementary Service Control entity 
uses, via the Coordination Function, the services of Generic Functional Procedures Control. 

Where an output symbol represents a primitive to the Coordination Function, and that primitive results in a message 
being sent, the output symbol bears the name of the message and any remote operations APDU(s) or notification(s) 
contained in that message. 

Where an input symbol represents a primitive from the Coordination Function, and that primitive is the result of a 
message being received, the input symbol bears the name of the message and any remote operations APDU(s) or 
notification(s) contained in that message. The following abbreviations are used: 



.inv 


invoke APDU 


.re 


return error APDU 


.rej 


reject APDU 


.res 


return result APDU 
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C.1 SDL representation of SS-MCR at the Requesting 
PINX 

Figure C.l shows the behaviour of an SS-MCR Supplementary Service Control entity within the Requesting PINX. 

Input signals from the right and output signals to the right represent primitives from and to the Requesting User and 
internal signalling, e.g. timer expiry. 

Input signals from the left and output signals to the left represent primitives from and to the Coordination Function in 
respect of messages received and sent. 



Make Call Request 
ind. 



to Co-operating 
PINX 



mCRequest.inv 



Start Timer T1 



from Co-operating 
PINX 



MClRequest.res 



Make Call succesful 
ind. 



m C Request. re j/err Timer T1 Expiry < 



Make Call unsuccesful 

ind. 



MCAIerting.inv 



Make Call Alerting ind. 



MCR idle 



Figure C.1 : SDL representation of SS-MCR at the Requesting PINX 
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C.2 SDL representation of SS-MCR at the Co-operating 
PINX 

Figure C.2 shows the behaviour of an SS-MCR Supplementary Service Control entity within the Co-operating PINX. 

Input signals from the right and output signals to the right represent primitives from and to the Co-operating User. 

Input signals from the left and output signals to the left represent primitives from and to the Coordination Function in 
respect of messages received and sent. 



MCRJdle 



Reject ind. 



yes 

Make Call Request 
ind. 



Accept ind. 



mClnform.inv 



MCR_Active 



mClnform.re 



mCRequest.re 



MCR idle 



From 

Requesting 

PINX 




To 

Destination 
PINX 



CONNECT - - 



From 

Destination 

PINX 



mCRequest.res 



To Requesting 



PINX 



ALERTING 



mCAIerting.inv 



Figure C.2: SDL representation of SS-MCR at the Co-operating PINX 
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C.3 SDL representation of SS-MCR at the Destination 
PINX 

Figure C.3 shows the behaviour of an SS-MCR Supplementary Service Control entity within the Destination PINX. 

Input signals from the right and output signals to the right represent primitives from and to the Destination User. 

Input signals from the left and output signals to the left represent primitives from and to the Coordination Function in 
respect of messages received and sent. 



mClnform.inv 



ALERTING/ 
CONNECT 



Make Call Information 
ind. 



Alert/Connect 
ind. 



Busy 
ind. 



Error 
ind. 



Figure C.3: SDL representation of SS-MCR at the Destination PINX 
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